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KXlOJUTIVE  SUMMARY 


The  "Trade-off"  is  a Keans  for  examining  the  interrela- 
tionships between  various  performancet  schedule,  and  cost  para- 
meters to  decide  whether  or  not  to  improve  one  element,  usually 
at  the  expense  of  another,  to  maximise  system  effectiveness 
and/or  the  probability  of  mission  success.  It  is  desirable, 
therefore,  to  provide  guidance  to  assure  that  trade-offs  are 
properly  made,  especially  in  the  performance  area;  to  quantify 
the  likelihood  of  meeting  or  exceeding  performance  requirements; 
and  to  assure  that  changes  in  the  likelihood  of  meeting  these 
requirements  can  be  tracked.  This  quantification  end  tracking 
process  is  called  Technical  Performance  Measurement  (TPM). 

Its'  purpose  is  to  identify  areas  of  potential  difficulty  early 
enough  for  corrective  action  or  possible  trade-off. 

TPM  began  emereing  as  a system  requirement  in  1967.  It 
was  introduced  formally  by  MIL-STD-499  (reference  (1)  of  the 
bibliography).  Since  that  time  TPM  has  proven  to  be  a useful 
tool  for  use  by  systems  engineering  management  in  the  Air  Force. 

It  has  also  been  proven  to  be  a useful  tool  in  certain  projects 
of  the  Navy,  the  AEGIS  project  for  one.  It  is  considered  de- 
sirable, therefore,  to  provide  guidance  applicable  to  perfor- 
mance measurement  factors  pertinent  to  ship  acquisitions  and, 
also,  criteria  for  using  TPM  outputs  and  conducting  trade-offs 
necessary  to  develop  practical  and  effective  ship  design  solutions. 


This  report  describee  the  general  nature  of  trade-offs  which 
can  be  made  during  each  phase  of  a ship  acquisition  project, 
explains  the  techniques  of  and  provides  a methodology  for 

using  the  outputs  of  TPM  in  trade-off  studies. 

The  material  for  this  study  was  obtained  by  rcssarching 
the  literature  on  systems  engineering,  especially  TiX,  and  by 
interviewing  knowledgeable  individuals  in  NAVSMIPS,  NAVOPD, 
and  the  Defense  Systems  Management  School. 
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GUIUELINES  FGH  MAKING  THAUEOFFS : THE 


SPECIAL  POLK  OF  TECHNICAL  PEPFORMANCE:  MEASl'PFEiENT  • 


1.  Introduction 


According;  to  reference  (2),  the  techniques  of  systems  per- 


formance effectiveness  have  evolved  from  endeavors  to  answer 


the  question  ...  "Mow  is  effective  systems  er>Kineerin(t  performed 


in  a real-world  environment?"  These  endeavors  l.ave  been  coupled 


to  the  life  cycle  costing  concept  because  this  concept  extends 


the  horizons  of  the  systems  engineering  effort  beyond  the  con- 


ceptual and  development  phases  and  makes  operational  and  sup- 


port concepts  and  cost  data  a necessary  input.  Thus,  designated 


Project  Managers  im])ose  cost  and  schedule  constraints  on  sys- 


tfMJis  engineering  management  as  well  as  the  technical  constraints 


reflected  in  operational  requirements.  Other  inputs  cover  the 


Project  Management  or  user  estimate  of  value  which  is  placed 


on  missions  and  tasks  to  be  performed  by  the  systems  being  de- 


veloped, and  historical  data  or  feedback  related  to  problems 


of  failure,  repair,  accident,  etc. 


Systems  engineering  then  must  take  these  inputs,  design 


a ship,  and,  simultaneously,  perform  effectiveness  analysis. 


‘ABSTAINER 


This  study  represents  the  views,  conclusions  and  recommendations 
of  the  author  and  does  not  necessarily  reflect  the  official  opinion 
of  ti.e  Defense  Systems  Management  School  nor  the  Department  of 

Defense. 
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In  these  analyses,  approaches/alternatives  are  varied,  aralyzed, 
and  optimized  until  an  output  results  al.irh  is  a r easure  of 
the  extent  to  which  the  ship  system  oiay  Le  expected  to  satisfy 
user  requirements  at  a certain  cost.  In  other  words,  the  life 
cycle  of  any  ship  includes  a continuing  series  of  compromises 
and  trade-offs.  They  occur  in  the  early  stages  of  the  life 
cycle  and  continue  through  engineering  development,  acquisition, 
deployment,  maintenance,  and  modifiration  until  the  ultimate 
trade-off  decision  to  discard  and  replace  witii  a higher  perfor- 
mance more  cost-effective  system  is  made.  The  principal  differ- 
ences in  these  trade-offs  concern  the  relative  values  assigned 
and  the  applicability,  from  pltaae  to  phase,  of  the  large  number 
of  variables  amenable  to  trnde-off.  Naval  ships,  of  all  major 
weapon  systems,  present  the  most  complex  problem  in  achieving 
meaningful  trade-off  decisions.  A naval  ship  is  a multi-purpose 
system  whose  active  life  usually  exceeds  the  life  span  of  con- 
tributing shipborne  systems  by  a factor  of  two  or  three.  Thus, 
trade-offs  and  optimizations  of  design  cannot  be  done  intuitively 


by  the  designers  with  the  various  factors  being  weighted  by 
personal  experience.  Instead,  all  technical  and  cost  factors 
as  well  as  devclopmei.t  time  must  be  identified  and  defined,  and 


2 
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stages  of  the  life  cycle,  by  specifying  detailed  nieasureicent 
procedures,  and  by  sl'.uuiiig  how  the  outputs  can  be  used  in  trade 
studies . 

2.  The  Nature  of  Trade-Offs  During  the  Ship  Life  Cycle 

Conceptual  Ef fort/Preliniinary  Design.  Trade-offs  con- 
ducted at  this  stage  of  development  cc.ncern  functional  capabili- 
ty at  the  highest  level  of  functional  indenture,  that  is,  trad- 
ing-off  among  the  various  types  of  propulsion  systems,  aonar 
systems,  or  weapon  systems  as  system  functional  requirements 
or  system  performance  parameters  are  varied  to  obtain  accept- 
able design  solutions.  For  example,  tlte  constraint  posed  by 
the  reliability  of  a prime  service-approved  shipborne  system 
candidate  may  cause  a trade-off  to  a shipborne  system  with  a 
higher  reliability.  There  might  also  be  trade-offs  to  save  weight, 
or,  trade-offs  resulting  from  model  tests  of  various  hull  forM. 
The  results  of  such  model  tests  serve  to  check  and  improve  the 
accuracy  of  estimates  of  resistance,  speed,  power  and  maneuvera- 
bility. Self-propulsion  tests  may  be  cotiducted  to  determine 
tlie  best  set  of  propellers  and  to  ctieck  ttie  actual  shaft  horse- 
power that  will  be  required  to  drive  the  ship  at  cruising  and 
top  speeds.  Such  model  tests  might  even  run  beyond  tbe  allotted 
time  assigned  to  conceptual  effort  or  preliminary  design. 

System  Contrtict  Design  (Validation).  During  this  stage, 
attention  is  directed  toward  the  more  detailed  aspects  of  indi- 
vidual systems  required  to  fulfill  requirements.  As  design 


id. 


J 


r 1 

progresses  toward  the  Total  Ship  Allocated  (Functions)  Baseline, 
the  primary  trade-off  area  shifts  to  such  things  as:  the  signal 
parameter;  the  details  of  form,  fit,  and  arrangement;  the  en- 
vironmental aspects;  weapons  and  ammunition  handling;  piping; 
ventilation  and  air  conditioning;  weights;  stability;  etc. 

Every  element  of  the  conceptual  development  or  preliminary  de- 
aign  is  reviewed,  checked  and  refined.  Wlienever  the  effect  of 
going  into  greater  detail  dictates,  necessary  changes  or  trade- 
offs are  made.  Engineering  feedback  on  sucii  tilings  aa  boilers, 
turbines,  machinery,  etc.,  is  especially  important  at  this  stage 
so  that  problems  with  these  areas  can  be  eliminated  in  new  de- 
signs. 

Detail  Uesigi:  and  Construction.  During  this  stage  a ship- 
builder and/or  a design  agent  develop  tlie  thousands  of  detail 
drawings  necessary  to  build  the  ship.  Some  drawings,  such  as 
overall  system  arrangements  may  require  ciiange  or  trade-offs 
as  necessary  to  meet  new  needs,  correct  an  incompatihility , 
etc.  As  time  goes  on,  however,  the  latitude  for  practical 
change  or  trade-off,  to  incorj'ornte  improver.ient , narrows.  Cost 
and  delay  are  very  i eal  considerations  at  this  stage  because 
shipbuilders  and  design  agents  are  obligated  by  contract,  and 
changes  not  cnly  delay  material  work,  but  also  involves  the 
slow  process  of  legal  approval,  acceptance,  and  compensation. 

Deployment  and  Disposal.  The  ship  as  a total  systewi  can 
be  expected  to  have  a longer  active  life  than  the  component 
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threat-countering  or  attack  systems,  support  systems,  subsys- 


tems,  and  enuipn<ert.  As  the  tlroet  changes  and  technology  pro- 
vides improvements,  continuing  analysis  is  required  to  ensure 
that  the  total  ship  system  capability  is  optimised  at  all  times. 

As  improved  component  systems  become  available,  each  is  con- 
sidered with  respect  to:  the  degree  of  capability  enhancement 

attainable;  compatibi  1 i ty  witii  otlier  component  systems  to  be 

retained  in  the  ship;  logistic  effects;  improvements  in  fleet  | 

standardization;  and  costs  to  procure  aid  Irstell  with  the  re-  J 

i 

1 

lationship  relative  to  the  remaining  effective  ship  life.  | 

1 

Decisions  regarding  the  degree  of  alteration,  modernization 
or  conversion  to  be  accomplished  are  recorded  in  Navy  planning 
documents  such  as  tlie  riess  Improvement  Plan  (CIP).  When  analy- 
sis or  inspection  has  established  that  the  ship  should  be  dis- 
posed of  the  decision  is  recorded  and  the  rationale  involved 
documented. 

3.  Introduction  to  Technical  Performance  Measurement  (TPM) 

According  to  reference  (1):  "TPM  is  the  continuing  demon- 

stration and  prediction  of  ttie  degree  of  actual  or  anticipated 
achievement  of  selected  technical  goals  or  objectives  of  a sys- 
tem or  part  thereof,  together  with  causal  analysis  of  the  vari- 
ance between  achievement  and  objective.  The  purpose  of  TPM 
is  to  permit  appropriate  managers  to  take  timely  action  on  in- 
dicated problems.'*  Reference  (3)  states  that  TVM  is  the  func- 
tion by  which  the  status  of  system  performance  characteristics 
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are  determined  durint^  development,  using  calculations  or  measure- 
ments  of  system  element  design  parameters.  Reference  (3)  fur- 
ther states  tl>at  the  total  function  consists  of  parameter  model- 
ing, planning,  njeasuring,  evaluating  and  reporting,  and,  it 
uses  normal  engineering  and  manageD>etit  activities  and  teclmiques 
to  the  greatest  extent  possible. 

TRM  is  not  really  a mystery,  as  evidenced  by  the  many  ref- 
erences on  the  subject  in  the  bibliography.  The  steps  in  set- 
ting up  a system  will  be  described  in  this  paper,  however,  if 
any  reader  is  serious  about  the  subject,  and  wants  to  set  up  a 
system  he  is  urged  to  read  references  (1),  (3),  (4),  (6)  and  (8). 
Although  the  objective  is  the  same,  there  are  many  rami fications. 
This  paper  describes  a system  based  on  subjective  probability 
distributions.  Such  a system  is  described  in  reference  (4) 
and  is  most  advantageous  when  hardware  does  not  exist,  that 
is,  hardware  which  can  be  tested,  or  measured,  to  determine 
status  of  performance  characteristics.  Indeed,  each  new  ship 
acquisition,  conversion,  or  fleet  modernization  project  should 
plan  and  execute  a TPM  effort  that  is  tailored  to  meet  specific 
project  needs.  The  effort  should  be  continuous  and  should  con- 
stitute the  tracking  of  tectinical  achievement  to  date  versus 
a forecast  of  expected  aciiievement  and  an  analysis  of  ary  varia- 
tions. Such  a system  will  contribute  to  trade  studies,  as  speci- 
fically required  to  support  the  decision  needs  of  the  ship  sys- 
tems engineering  effort. 
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The  steps  in  nueaeuriDg  and  tracking  teclmical  performance 

are: 

a.  Determine  the  performance  variables  essential 
for  technical  success  and  establish  performance  functions  or 
equations  ahich  relate  performance  variables  (outputs)  to  de- 
sign variables  (inputs).  Performance  equations  which  specify 
relationships  between  design  variables  (inputs)  and  performance 
variables  of  interest  ^outputs)  may  be  selected  froni  tlie  Tech- 
nical Manual  of  the  Maval  Ship  Systems  Command  (NAVSIIIPS)  or 
otherwise  developed  for  use  in  the  TPM  program.  Typical  ship 
performance  variables  are:  V,  speed  in  knots  (nautical  miles 

per  hour);  R,  range  in  nautical  miles;  and  E,  endurance  in 
hours.  Ship  design  variables  are:  L,  length  in  feet;  W,  dis- 

{^cement  in  long  tone  (2240  pounds  per  ton);  P,  installed 
shaft  horsepower;  and  F,  weight  of  fuel  in  long  tons.  Typical 
ship  perfortuance  equations  are: 


Where,  PC  is  a propulsive  coefficient  and 
DC  is  a draft  coefficient.  These 
coefficients  varj'  depending  on  the 
ship  type.  K is  a constant. 
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(2)  Range 


1/3 


X 

(LW)^^  X OSFC 
Where,  OSFC  depends  on  power  plant  type  and  j 

represents  overall  specific  fuel  con- 

I 

sumption  in  pounds  per  installed  j 

shaft  horsepower  per  liour.  is 

a constant. 

(3)  Endurance 

« 

F = K X F X 1 

^ P 

OSFC 

Where,  is  a constant. 

The  foregoing  example  performance  equations  specify  a relation- 
ship betuecn  design  variables  nr(’  scr.ie  perforr.arce  varinble  of 
irterest.  This  relr t ionsliip  may  be  known  from  first  principles, 
inferred  froni  experimental  data,  or  contain  elements  of  each. 

Some  of  the  design  variahles  may  be  known  exactly.  In  other 
cases,  knowledge  may  be  much  less  certain,  fbr  example,  one 
might  have  a technical  objective  to  develop  a new  power  plant. 

Hence,  OSFC  in  equations  (2)  and  (3)  would  not  be  known  exactly. 

In  any  case,  the  ultimate  objective  of  developing  sucli  relatioii- 
ships  is  to  quantify  the  likelihood  of  meeting  or  exceeding 
performance  specifications  in  time  to  make  trade-offs,  or  take 
corrective  action. 

b.  Develop  subjective  probability  distributions  for 
the  design  variables,  the  inputs,  by  making  inquiries  of  design 


R = Kj  x F 


PC 

DC 
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IF 


personnel*  According  to  reference  (4),  the  interview  technique 
systematically  draws  from  a man's  men^oiy  of  liis  past  experiei  ces 
(including  test  results)  ttie  information  necessary  to  recon- 
struct a range  of  expected  design  values  (inputs),  and  tiie  as- 
sociated probabilities.  For  each  design  variable,  estimate 
ranges  of  values  and  probabilities  of  occurrence  over  the  range. 
For  example: 

Design  Variable  Range  Probability 


OSFC 

.50  - .55 

.3 

.55  - .SO 

.5 

.60  - .65 

.2 

c.  Use  appropriate  techniques  (e.g.,  simulation)  to  deter- 
mine the  likelihood  of  meeting  technical  objectives,  or  of  ob- 
taining desired  perforn.ance  (e.g.,  speed,  range,  endurance,  etc.). 
A sample  array  for  V,  R,  and  E,  and  associated  probabilities, 
p(V),  p(K),  p(E),  is  given  below: 

PKCDABILITY  DISTHIBUTK  NS  FOR  SYSTEM.  PRKFC'KMANCK  CHARACTERISTICS 
(OUTPUTS)  IN  A HYPOTHETICAL  SHIP  DEVELOPMtJJT  PROJECT 


V (knots) 

16 

17 

lb 

19 

20 

p(V) 

.15 

.20 

.45 

.10 

.lo 

R (miles) 

4000 

5000 

6000 

7000 

8000 

p ( 1 . ) 

.10 

.20 

.40 

.25 

.05 

F (hours) 

3800 

4000 

4300 

4400 

4500 

p(  E) 

.25 

.35 

.20 

.10 

.10 

d.  Track  changes  in 

the  likelihood 

of  meeting 

performanc 

objectives . 

An  example  of  this 

tracking 

process  is 

giver,  for 

ship  s]>eed 

in  Ap]ieiidix  A, 

Tab] es 

I and  II 

and  Figures  1 and  2f 

pages  A-1  and  A-2. 
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An  analogous  system  was  described  by  I''.  S.  TIMSCN,  in  reference 
(4;.  Other  sample  output  reports  are  also  shown  on  pages  A-3,  4 
and  5 in  Appendix  A,  Figures  5,  4,  and  5.  These  sample  reports 
were  taken  from  references  (3),  (6)  and  (7)  respectively. 

4.  Guidelines  for  implementing  TPM 

T’eference  (8)  contains  an  excellent  sununary  of  TF>M  imple- 
mentation requirements.  According  to  reference  I8):  "When 

you  boil  it  all  down  the  requirements  contained  in  MIL-STD-499 
concerning  TPM  are  essentially  to  plan  everything  and  then  to 
perform  in  accordance  with  the  plans.  Three  basic  topics  are 
evident.  The  first  is  planning  itself.  Tlie  parameters  to  be 
measured,  to  what  standard,  when,  under  what  conditions,  the 
values  expected,  who  is  responsible,  etc.,  are  all  to  be  planned 
in  detail  and  documented.  Secondly,  the  evaluation  efforts, 
obtainine  observed  values,  preparing  predicted  values,  and 

i 

identifying  variance  at  levels  below  reportin'^  elements  are  , 

then  all  performed  in  accordance  with  the  TPM  plan.  In  fact 

j 

all  efforts  to  compare  perfornance  with  specified  values  are  j 

to  be  included  in  the  TF’M  plan.  Likewise  the  reporting  routines,  | 

variance  corrective  action  process,  the  determination  of  the 
impact  of  out-of-tolerance  conditions  and  follow-up  management  ] 

actions  are  all  conducted  in  accordance  with  the  same  TPM  plan.  j 

I 

Certain  key  elements  are  necessary  in  the  implementation  of  a j 

Trtl  program.  These  elements  essentially  in  their  order  of  oc-  : 

I 

currence  are:  j 


J 
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--  Selection  of  Partnneters  and  Detail  Documentation 


--  T«-«  Models 
— Parameter  Profiles 
— TPM  Plan 

— Organizational  Part  i r ii>at  i on 
--  Pepcrts  ail’  iormats 

--  Analysis,  Predictions,  and  Impacts" 

This  paper  does  not  address  all  of  the  aieas  necessary  for 
TPM  implementation.  Those  individuals  who  ore  really  interested 
should  read  reference  (8)  and  other  more  detailed  references 
on  the  subject.  This  paper  does  address  those  implementation 
areas  which  are  considered  most  iirportant  from  a Ship  Acquisi' 
tion  Project  Management  v^oint  of  view.  TPM  math  models,  reports 
and  fom;ats  have  alreiidy  h»er  nddtessed.  TPM  plars  and  organi- 
zational participation  will  not  be  addressed  at  all  because 
plans  must  be  tailored  and  participants  change  so  frequently. 
Suffice  to  say  tliat  plans  and  organizational  responsibilities 
must  be  spelled  ovit.  Now  let's  look  at  selection  of  paraireters; 
parameter  profiles,  and;  analysis,  predictions,  and  impacts. 

a.  Selection  of  Parameters.  According  to  reference  (fi), 
all  parte  of  a Work  Breakdown  Structure  (HBS)  which  have  cost 
and  schedule  factors  assigned  may  not,  in  fact  the  majority 
probably  will  not,  have  TPM  parameters  associated  with  each. 

In  practice,  TI’M  parameters  should  be  selected  for  one  or  more 
of  the  following  reasons:  mission/task  critical;  state-of-the-art 

11 
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critical;  and/or  will  be  incentive  related  or  be  contractually 


required.  All  parametera  must  be  measureable.  A miseion/taak 
critical  paiar.eter , for  exanrple,  may  be  ebip  speed  or  ran^e  or 
endurance,  or  it  may  be  associated  with  a subsystem  such  as  a 
radar.  Important  radar  performance  parameters  are  range  and 
resolution.  In  any  case,  the  parameter  selected  for  measure- 
ment should  be  important  and  difficult  to  achieve.  We  night 
say  that  the  degree  of  technical  risk  will  be  mediun-to-high. 

In  ship  acquisition  projects,  the  selection  of  per- 
form.iince  pni'ameters  should  begin  during  the  cor.ceptual  effojt. 

In  fact,  where  shipborne  systens  are  being  developed  by  other 
system  commands,  "measurement"  should  begin  during  the  ship 
conceptual  effort.  This  can  be  accomplislied  by  including  appro- 
priate requirements  in  Ship  Project  Directives.  The  AEGIS 
missile  system  project,  for  example  is  already  implementing  a 
comprehensive  TPM  systeiri.  Normally,  ship  related  parameters 
should  be  selected  during  the  contract  design  or  validation 
phase.  It  is  extremely  important  to  have  "potential  difficulty" 
information,  especially  on  GFE,  early  enough  to  institute  a 
trade-off  and  fallback  to  more  mature  equipment. 

Up  to  the  present  time  a TPM  systcni  has  not  been  in 
use  in  Ship  Acquisition  Project  Management  Offices.  A more 
efficient,  more  formal,  system  is  considered  desireable,  however. 
This  is  especially  true  with  respect  to  cooiplex  shipborne  sys- 
tems. It  would  be  wise,  1 tliink,  for  a Ship  Acquisition  Project 
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Manager  to  require  tliat  participating  managere  provide  current 
infonaation  on  how  they  are  doing  technically.  To  repeat,  this 
is  esj)ecic»lly  ini^ri  tai.t  in  OFE  areas  tiiat  exi.ibil  high  r isk. 

Shipbuilders  nay  also  be  retpiii'ed  to  provide  information  on 
selected  parnrieters  by  a contract  clause  such  as  the  foUowing: 

"The  contractor  sliall  prepare  and  submit  for  approval  a list 

of  TPM  parameters  consistent  with  the  detail  specifications,  i 

and  measure  and  report  thereon  monthly  in  accordance  with 
Contract  Data  Requirements  List  Data  Item  , Technical  Perfor- 

mance Measurement  Report".  A sample  Data  Item  Description, 
l>D  Form  lf>64.  "TPiM  Report"  ard  associated  sample  reports  are 
ii.cluded  in  Appendix  A,  pages  A-6  through  A-11.  ' 

b.  Parameter  Profiles.  The  sample  Data  Iten;  Description 
mentioned  above,  includes  a Figure  2 which  is  a suggested  TPM 

parameter  profile  and  graphic  reporting  format.  See  page  A-15.  ] 

! 

It  shows  a line  for  the  planned  parameter  value,  and  an  upper 
and  lower  tolerni.ee  limit.  The  lower  tolerance  limit  is  the 

I 

only  lire  v.b.ich  should  trigger  a variance  ar.nlysiF.  A value 
p.bo\  e the  upper  limit  indicates  that  specification  require- 
ments will  be  exceeded  and  ro  variance  analysis  should  be  re- 
quired. Unless  aii  interface  will  be  affected,  therefore,  it 
is  suggested  tl.at  only  the  lower  limit  he  shown.  In  any  rase,  j 

profiles  are  necessary  ard,  according  to  lefei erce  (8),  serve 
tlie  following  functions:  j 
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• Give  a vit?ual  preaentation  of  progreBa  history  and 
program  goals 

• Pelate  time,  performance  and  analysis/test  events 
on  one  page 

’ Provide  the  criteria  for  variance  reporting  during 
the  life  cycle  of  the  parameter,  and 

• Provides  a meciionism  for  presenting  predictions 
and  planned  corrective  action  results. 

Here  again,  the  existence  of  a large  tolerar.ee  between  tiie  mini- 
mum profile  end  the  required  value  line  tends  to  indicate  a 
greater  uncertainty  in  attaining  parameter  performance,  and 
will  tend  to  focus  attention  on  a probable  technical  risk. 

What  it  says  simply  is,  if  I do  worse  than  this  minimum  perfor- 
mance at  the  particular  time  shown,  I probably  can't  get  there 
from  here;  therefore,  some  change  of  jilnn  or-  coireciive  rtclian 
is  called  for. 

c.  Analysis,  Prediction  and  Impacts.  According  to  refer- 
ence (8);  "The  ground  rules  presently  proposed  for  reporting 
a variance  is,  wl.enevei'  a plnrned  evaluation  or  test  result 
falls  below  the  minimum  parameter  profile,  a variance  exists 
and  tiie  variance  analysis  report  is  required.  Engineering  per- 
sonnel responsible  for  the  technical  parameter  in  variance  must 
prepare  the  analysis,  the  corrective  action  plan,  and  the  re- 
vised predicted  value  of  the  paramel ei . " In  fact,  knowledgeable 
personnel  should  provide  trade-off  rocomn.endnt  i or  s , if  reces^nIy, 
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The  rest  of  tliie  rape*"  ri«*scriln*a  »-onc  of  Hie  factors 
tl.at  Eiiifct  te  considered  in  trnde-off  studies. 

5.  Factors  to  be  Considered  in  t'sing  TPM  Outputs  in  Tradeoffs. 

Trade-offs  are  used  to  obtaiii  a ijrncticel  balance  between 
cost,  schedules,  and  perfoiwar.ee  of  systenis.  In  this  context, 
cost  includes  all  costs  of  acquisition  and  ownership;  perfor- 
mai:ce  includes  all  factors  influencintr  effectiveness  in  opera- 
tional use  such  as  reliability  and  n aintainabi 1 ity ; and  systen. 
includes  all  hardware  and  other  required  items  such  as  facilities, 
personnel,  data,  training,  and  equipment. 

The  weight  factor  or  relative  value  assigned  to  various 
elebients  and  their  specific  applicability  is  subject  to  wide 
variation.  Depending  on  the  particular  program,  the  accepta- 
bility of  risk,  fiscal  or  political  considerations,  or  personnel 
ceilings  may  take  precedence  over  each  other  at  any  given  time. 
However,  the  fundamental  considerations  are  that  tl.e  apprewed 
choice  must  be  finai.cially  acceptable,  be  technically  feasible 
and  have  tl.e  required  performance  capability,  be  militarily 
useful,  and  be  available  in  a timely  manner. 

a.  Costs  and  Benefits.  Whenever  the  output  of  a Tl^ 
systeni  triggers  a trade-off  study,  costs  and  benefits  will  al- 
ways be  driving  forces.  Reference  (9)  includes  pertinent  guide- 
lines applicable  to  such  considerations.  These  guidelines  are 
summarized  in  the  following  paragraphs. 
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Fxceptions  to  cost-lx-r.efit  aualytiie,  as  well  as  ex- 


i 

[ 

! 

i 


ai.^les  of  ii.vt'staieiit  proposals  to  which  sucli  analysis  apply, 
should  be  as  specified  in  SECNAVINST  7000.14  of  30  Jan  1970. 

In  general,  cost-benefit  analysis  should  be  performed  when  the 
specific  objective  is  to  identify  one  of  the  following: 

• The  alternative  whicli  is  expected  to  produce  the 
needed  benefits  or  effectiveness  for  a given  cost  level. 

(The  Equal  Cost  Criterion) 

• The  least  costly  alternative  of  several  equal  ly 
effective  ways  to  achieve  an  objective.  (The  Equal  Effective- 
ness Criterion) 

• The  relative  cost  of  various  alternatives  and  the 
effectiveness  that  car.  be  provided  sc  a judi;rer.t  con  be  pade 

as  to  wl. ether  increased  effectiveness  is  worth  additional  cost. 

(The  bneoual  Cost/Unequal  Effectiveness  Criterion) 

The  definitions,  otaximum  economic  lives,  the  discount 
rate,  and  the  discount  tables  associated  with  cost-benefit  j 

analysis  are  to  be  as  specified  in  SECNAVINST  7000.14  of  30 
Jan  1970. 

*'  The  Equal  Cost  Criterion.  When  benefits  are  a 
determining  factor,  the  alternative  which  yields  the  needed 
benefits  (or  effectiveness)  for  a given  level  of  cost  should 
Ic  |»referied.  This  criterion  should  also  apply  to  in)-cr.st 
ctianges.  Under  this  criterion  a detailed  investigation  of 
benefits  should  be  undertaken  to  determine  which  alternative 
provides  the  needed  level  of  benefits  best. 


. ^ .1  V 
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When  ii»e  values  are  in  effect  (i.e.,  benefits  not 
expressed  in  dollars)  benefits  associated  with  the  status-quo 
and  all  optiona/alternativea  may  be  either  listed  or  scored. 
Assuminf;  equal  risk,  the  option/alternative  with  the  f^reatest 
benefits  or  the  highest  score  is  preferred.  See  the  paragraph 
followirg  dealing  witl*  unequal  cost/unequal  effecti veress  for 
guidelines  appropriate  to  eltiiatiuis  of  unequal  risk. 

Usually,  market  values  do  not  apply  (i.e.,  benefits 
expressed  in  dollars);  however,  when  they  do,  it  is  necessary 
to  estimate  the  discounted  cash  flow  income  or  revenue  result- 
ing from  the  specified  investment.  This  requires  a prediction 
of  future  volume/demand  at  a specified  unit  price.  At  best, 
tills  requires  skill,  experience,  and  luck  because  there  is  no 
satisfactory  way  to  predict  tlie  future.  It  is  recommended 
that  statistical  data  on  past  revenues  be  collected,  or  that 
a marketing  survey  be  conducted  to  obtain  sample  data.  Cnee 
this  data  is  collected,  it  should  be  aibjected  to  statistical 
analysis  to  obtain  predictions  (at  tbe  95%  confidence  level) 
of  future  income.  Here  again,  assuming  equal  risk,  the  option/ 
alternative  which  promises  the  highest  income  or  revenue  is 
preferred . 

••  The  F.quel  Effectiveness  Criterion.  When  alterna- 
tive investment  proposals  for  achieving  a given  objective  all 
provide  a specified  level  of  benefits,  the  alternative  with  the 
lowest  discounted  cost  is  preferred  (assumiiig  equal  risk). 


Tliie  criterion  is  cal  loti  llie  "equal  ef fectivcress"  criterion. 

When  this  criterion  is  need  it  is  not  really  recessary  to  conduct 
a detailed  investigation  of  benefits  because  it  is  asauned  all 
options/alternativea  will  yield  the  same  benefits.  It  is  neces- 
sary to  conduct  a detailed  investigation  of  costs,  especially 
life  cycle  costs,  to  justify  selection  of  an  option  or  alter- 
native. In  fact,  the  "savings"  resulting  from  the  lowest  esti- 
mated life  cycle  cost  asay  be  sufficient  justification.  Unless 
contracts  or  cost  estimates  for  budgets  are  involved,  alterna- 
tives may  be  cvaluutod/justified  on  a I’elntive  cost  basis,  as 
long  as  estimates  arc  coriparotively  correct,  and  as  long  as 
absolute  estifliates  cani.ot  be  developed  by  extrapolating  the 
cost  of  similar  previously  developed  systems.  When  the  new 
systeni,  or  option/alternative,  is  radically  different  from  the 
previous  one  (and  this  is  becoming  increasingly  common)  abso- 
lute cost  estimates  may  he  nothing  more  than  educated  guesses. 

When  contracts  are  Involved,  it  is  necessary  to  get  an  absolute 
estimate  of  cost  from  the  contractor  before  an  evaluation  of 
the  impact  of  a change  can  lie  made. 

In  any  case,  costs  must  be  conipared  to  a conirior  base. 

Where  systems  ai'e  in  existence,  tot(»l  costs  ray  not  irclude 
dev elopmci'ta]  costs  but  oi  ly  i>i  ocui  emert  and  maintenance  costs 
over  the  comparative  time  period.  Where  systems  under  develop- 
ment arc  in  competition  with  existing  syatems,  the  cost  basis 
utilized  must  he  sucl>  as  to  ensure  that  comparability  is  maintained. 
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Where  all  the  competitive  alternativea  are  developmental • total 
life  cycle  costa  are  the  preferred  basis  for  comparison.  In 
making  estimates,  great  care  miiet  be  exercised  to  ensure  that 
assumptions  utilized  in  assessing  costs  are  realistic.  In 
figuring  cost  trade-off  factors,  tlie  relative  value  of  eli«iinat- 
ing  or  retaining  optional  functions  should  be  considered. 

• • Tlie  Unequal  Cost/Uncciual  Effectiveness  ion . 

Generally,  tliere  is  no  al l-purpose  criterion  for  identifying 
the  preferred  option/alternative  in  cases  v.here  both  benefits 
and  costs  are  unequal.  Project  Managers  are  confronted  with 
a large  number  of  competing,  and  often  equally  valid,  require- 
ments which  they  must  reconcile.  I'sually,  they  are  faced  with 
opt  ioi^s/al  tel  rati  ves  ti.et  offer  increased  benefits  at  ar.  in- 
crease in  cost. 

Whether  market  values  or  use  values  apply,  the  ratio 
of  needed  level  of  effectiveness  to  cost  should  be  used  to  de- 
termine gain  per  dollar  spent.  When  market  values  apply,  it 
is  necessary  to  estimate  discounted  income  and  costs  os  indi- 
cated in  the  paragraphs  preceding,  when  use  values  applj , 
benefits  associated  with  the  status-quo  and  all  options/elter- 
ratives  should  he  listed  or  scored,  '’’he  jiercentage  change  in 
tiie  options/alternatives  from  tlie  status-quo  may  then  be  com- 
puted. Once  this  is  arcompl ished  the  decimal  equivalent  of 
the  percentage  change  n.aj  he  added  to  or  subtracted  fron.  ore, 
as  tl.c  case  r.ny  be,  to  obtain  an  expected  value  of  berefils. 


r 


1 

j 

j 

The  f>an;e  procedure  mny  theri  be  followed  with  respect  to  costs; 

i.e.,  estimate  the  cost  of  the  status-quo  and  all  options/al-  | 

ternatives  and  then  compute  the  percentage  change  in  ttie  options/ 

alternatives  from  the  status-quo.  Once  this  is  accomplished, 

the  decimal  equivalent  of  the  percentage  change  may  be  added 

to  or  subtracted  from  one,  ns  the  case  may  be,  to  obtain  a 

••scored”  value  for  costs.  This  v.-»lue  for  costs  may  then  be 

divided  into  tlie  value  foi  hci  efits  to  obtain  a ratio  of  bti  e- 

fi ts-tc-ccsl . Assuming  equal  risk,  the  option/alternati ve  with 

the  higliest  score  or  payoff  (P)  greater  than  one  is  preferred. 

^hen  risk  is  not  equal,  tlie  cption/alternative  with 
the  lowest  risk  and  the  highest  payoff  is  preferred.  It  should 
be  obvious,  however,  that  sevei'aJ  alterrrtives  ripj  to  aprtoxl- 
irately  equival  cr.t  ever  tieugl  I'ayoffs  oiiC  risks  are  unc'.ual. 

Tn  Ihi'  ,-iliialjcr  the  criterion  for  estaMishii.g  Tuderitii-s 
and/or  for  selecting  an  option/alternati \e  is:  choose  the  op- 

tior/alternative  for  which  the  ratio  of  payof f-to-risk  is  the 
highest.  For  example:  an  option/alternative  with  a payoff  of 

4.1  and  a risk  of  1.1  is  preferred  over  an  option/alternative 
with  a payoff  of  4.3  and  a risk  of  1.2.  The  ratios  of  payoff- 
to-risk  are  3.72  and  3.5t<,  respectively.  These  ratios  may  be 
called  "Preference  Numbers."  In  the  example  citeil,  they  indi- 
cate th.'il  il.e  snallrr  payoff  is  piefeijod  If.  1Je  t n1 

more  variable  (higher  i i sk ) payoff. 
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b.  Risk.  Risk  may  be  defined  as  the  subjective  proba- 


M3ity  of  fniliiie  to  rio«t  i <‘«iii  i or  cits  oi  otjrctivee  governing 
technical  characteristi ct , budgeted  funding  levels,  or  schedules. 
Wherever  trade  studies  are  being  conducted,  the  degree  of  risk 
associated  with  each  alternative  should  he  identified  and  as- 
sessed, and,  if  a risky  alternative  is  selected,  tliat  risk  must 
be  controlled.  TPM  plays  a duel  role  in  the  risk  management 
process.  First,  it  helps  to  identify  teclrical  risks  and  second, 
it  J.eli>s  ns  to  ecr-tiol  risk  hy  ketjing  tr.'ick  of  teclrical  i-i  o- 
gress . 

'’'cchnical  risks  may  appear  when  we  attempt  to  intro- 
duce features  whicli  have  not  been  successfully  developed  or 
constructed  before.  Other  causes  of  technical  risk  are  inade- 
quate definition  of  operational  perforniance  ot)jectives  (uncer- 
tainties in  requirements),  insufficient  hardware <femonst rati  or 
of  OFE,  aid  lack  of  trained  and  experienced  technical  peiscnrel. 
Because  of  ♦Isese  situations  there  is  always  a chance  that  per- 
fomumce  requirements  will  not  be  met,  or  there  will  be  relia- 
bility/mHintainability  problems,  or  service  approval  will  be 
denied,  etc. 

Technical  risks  associated  with  TDi  parameters  may 
he  assessed  qualitatively  or  quantitatively  and  may  be  classi- 
fied as  HlhH,  MEDIITM,  or  LOV,  .here  definitions  of  HIGH,  MEDIPM, 
and  LCT  must  be  generally  understood  and  accepted  by  everyone 
associated  with  a narticular  project.  The  degree  of  risk  may  be 
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asHessed  based  on  the  variance  around  a TPM  profile,  or  it  may 
be  assessed  based  on  a lack  of  resources,  for  example,  a lack 
of  input  information,  capabilities,  or  knowled;;e.  The  dei;ree 
of  risk  may  also  be  quantified  by  a simple  scorinr  process. 

For  example,  a score  from  1.0  to  2.0  would  signify  LOW  risk  -- 
a score  from  2.1  to  3.9  would  signify  MEDIUM  risk  — and  a 
score  from  4.0  to  3.0  would  signify  HIGH  risk.  The  consequences 
of  failure  to  achieve  a requisite  technical  characteristic  may 
be  expressed  by  a value  which  represents  an  increase  in  cost. 

In  other  words,  the  consequences  of  failure  to  solve  a techni> 
cal  problem  may  be  a large  cost  increase.  Such  a technical 
problem  may  be  quantified  in  risk  terras  as  follows: 


fHigti  Probability  1 

1 High  Cost  Impact  I 

HIGH 

of  Failure 

S 

1 of  Failure  1 

“ RISK 

1 

X 

5 

5 

As  noted  above,  TPM  may  be  used  as  a n.eans  of  i isk 
cci.trol  because  it  will  help  us  monitor  technical  aclil cveri-ent 
in  design  and  hardware  develojwiert  in  key  GFE  ard  in  all  other 
areas  of  a ship 

c.  Operational  and  Perfornatice  Factors.  Operational 
and  perfortaance  factors  constitute  prime  areas  of  consideration 
when  making  trade-offs.  For  example:  operational  factors  to 

be  considered  are:  --  The  basic  threat  which  is  the  basis  for 

the  mission  and  functional  requirements  --  mission  requirements 
for  each  system  in  terms  of  the  relationship  to  other  systems  -- 
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and  anticipated  deployment  coneiderat ions , such  as  number  of 
installations,  and  operational  locations. 


With  respect  to  ship  perfomii<nce,  trade-offs  must 
be  made  keepini;  in  mind,  for  example,  the  minimum  acceptable 
values  of  variables  such  as  speed,  ranee,  or  endurance  and  other 
essential  aspects  of  ship  system  perfonrance.  Also,  the  func- 
tional capabilities  of  shipborne  systems,  subsystems,  or  eouip- 
meuts  that  must  be  compared  and  evaluated  aeainst  the  mission 
requirements  comprising  the  performance  envelope  must  be  con- 
sidered. For  example:  the  functional  requirement  "conduct 

surface  surveillance"  may  be  satisfied  by  a relatively  simple 
short  range  radar  system  with  a Figure  of  Merit  (F.O.M.)  given 
in  terms  of  a Performance  Measure  (P),  tlie  Equipment  Operational 
Readiness  (EOR),  and  cost.  The  equation  is: 

Cost  Effectiveness  (F.O.M.)  = (P)  x (EOR) 

Life  Cycle  Cost 


Where, 

ESTIMATED 

EvSTIMATED 

SYSTEM 

SYSTEM 

P (RADAR)  = W, 

RANGE 

w 

RESOLUTION 

1 

ACCEPTABLE 

ACCEPTABLE 

RANGE 

RESOLUTION 

L 

Estimated  system  range  and  resolution  may  be  obtained 
from  the  TPM  system.  In  any  case,  the  equation 

is  a simple  two-dimensional  performance  vector  with 

weighting  factors  and  assigned  to  indicate  the 

relative  importance  of  the  respective  dimensions. 

In  effect,  these  numbers  are  subjective  military  worth 

assessments  which  can  be  conveniently  divided  into 
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eleven  categories  (or  any  number  of  categories)  as 
defined  below  and  in  reference  (IC). 


Weight  Regarding  Applicability  Regarding  Importance 


1.0 

Completely  Applicable 

Extremely  Important 

0.9 

Nearly  Always  Applicable 

Highly  Important 

0.8 

Highly  Applicable 

Very  Important 

0.7 

Frequently  Applicable 

Important 

0.6 

Generally  Applicable 

Fairly  Important 

0.5 

Probably  Applicable 

Probably  Important  ; 

, ) 

Some  Importance 

O.d 

Moderately  Applicable 

0.3 

Occasionally  Applicable 

Of  Little  Importance  , \ 

! i 

0.2 

Rarely  Applicable 

» j 

Vary  Little  Importance  j 

0.1 

Nearly  Always  Applicable 

Unimportant  ' | 

0.0 

Completely  Inapplicable 

No  Imoortance  Whatever  i 

• f. 

i' 


EOH  is  the  probability  that  a system  will  operate  j 

satisfactorily  throughout  an  interval  of  time  (t^  - t^)  = t. 

ECK  is  discussed  in  reference  (11)  and  is  defined  by  the  follow- 
ing equation: 

EOR  = e 

1 ♦ X(3 

Where  ^ = failure  rate  ■ 

I 

^ 3 Mean  Down  Time 

d.  Physical  Parameters  and  Limits.  Even  though  TPM 
only  provides  outputs  in  the  perfumiance  area,  physical  elements 
such  as  size,  weight,  and  service  requirements  require  careful 

i 

T 

t 
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thought  when  trade-offs  are  being  considered.  For  example: 


• Weights  — Evaluate  weight  limits  and  moment  affect. 

• Dimensions  --  Size  and  shape,  crew  space,  operator 
station  layout,  and  maintenance  accessibility  should 
be  considered. 

• Requirements  for  transport  and  storage.  These  require- 
ments include  such  items  as  tie  downs,  pallets,  battens 

and  containers. 

• Durability  and  ruggedness  factors. 

• Special  requirements  for  safety  or  health  including  con- 
siderations of  explosive,  mechanical  and  sociological 
effects. 

• Command  and  Control  requirements.  Evaluate  the  require- 
ments for  support  system  or  equipment  inputs  necessary 
for  the  system  under  consideration  to  function  properly. 

• Vulnerability  factors  of  competing  systems  including 

atomic,  chemical  biological,  radiological,  electromag- 
netic radiation,  fire,  and  shock  considerations.  j 

1 

e.  Pel  lability.  Considerations  of  reliability  are  of 

i 

major  concern  in  system  selectior'.  Expressions  of  reliability  i 

for  evaluation  and  comparison  between  competing  systems  should  I 

I 

-I 

be  expressed  in  quantitative  terms  wherever  possible.  However, 

I 

whether  the  comparison  be  quantitative  or  qualitative,  the 

I 

measurements  must  be  to  the  same  criteria  for  all  systems  under 

consideration.  To  the  degree  feasible,  system  reliability  should 

be  broken  down  into  the  reliability  of  component  subsystems  1 


and  equipment.  Thiu  breakdown  will  permit  ready  evaluation  of 
the  effect  of  trade-offs  at  the  subsystem  or  equipment  level. 

f.  Maintainability.  Assessment  of  maintainability  for 
trade-off  purposes  should  include  evaluation  of  such  factors  as 

• Level  of  Maintenance  required  (ships  force,  tender, 
shore  based  repair  facility) 

• Ease  of  component  or  unit  replacement 

• Commonality  and  interchangeability  of  units 

• Autccatic  test,  clieckout  aid  fault  location  features 

• Preventive  maintenance  requirements 

• Spare  part  lopistics 

• Equipmeiit  accessibility 

g.  System  Availability.  Evaluation  of  the  reliability 
and  maintainal)i 1 ity  combination.  this  evaluation  will  enable 
forecasting  a system  avai  Itibi  lity  at  any  given  time. 

h.  Personnel  Factors.  Personnel  factors  include  an  as- 
sessment of  each  competing  system  in  the  light  of  maiining,  skill 
level,  training  and  human  engineering  requirements  or  problems. 
This  estimate  also  provides  an  insight  into  relative  system  or 
equipment  complexity. 

• Manning.  Evaluate  for  each  system  the  manpower  required 

for  both  operation  and  maintenance.  Items  to  be  con- 
sidered include:  ranks  and  ratings;  job  classification; 

numbers  of  personnel;  and,  in  cases  where  alternatives 
are  being  considered  to  replace  an  operating  system. 
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chan^ef)  in  marninK  reiini renienta . 

• Traininp,.  Evaluate  i epiii rer.ents  for  specialized  train- 
ing, prerequisite  skills,  length  of  training  required, 
and  other  similar  factors  which  may  affect  tl>e  timely 
and  optiirupi  utilization  of  the  systeiris  being  considered. 

• Human  Engineering.  This  area  requires  evaluation  of 
ai.y  man-machine  problem  inherent  to  alternatives  under 
consideration. 

i.  Faci lities.  Evaluate  any  requirements  for  construc- 
tion, purchase  or  development  of  new  or  different  advance  base,  1 

training,  repair,  logistic,  and/oi-  otlier  facilities  or  systems 

in  order  to  support  an  alternative  under  cons  id  era  ti  on.  Tl>e 

assessment  should  also  include  an  evaluation  for  achieving  the  j 

j 

objective  through  modification  of  existing  external  facilities 
or  support  capabilities. 

j.  Compatibility.  In  the  development  of  a ship  system  ■ 

as  an  engineering  and  functional  whole,  the  compatibility  of 
interfacing  threat  countering  or  support  systems,  subsystems  or 

equiiwient  is  of  parairount  importance.  For  this  reason,  and  to 
ensure  that  no  interfacing  parameter  is  inadvertently  overlooked, 
each  trade-off  aralyses  should  include  a separate  assessment 
of  all  factors  which  affect  compatibility.  In  the  conduct  of 
the  compatibility  evaluation  of  competing  alternatives,  require- 
ments may  be  disclosed  which  indicate  a requirement  for  buffers 
to  ensure  compatibility.  Tliese  buffers  along  with  their  related 
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costs  mist  be  included  ii.  tbe  overnll  evaluation  of  tliat  par- 


i 

It 

} 


I 

I 

j 


ticular  alternative. 

k.  Standardization.  The  defense  standardization  program  | 

i 

acts  as  a constraint  on  the  systems  engineering  effort  because  j 

it  influences  the  trade-off  decisions  made  during  tlie  effort. 

This  influence  is  felt  liecause  tne  program  seeks  to  control 
the  variety  of  items  required  to  build  aid  maintain  a system. 

( 

Specific  objectives  are;  (l)  identicality  in  design  and  hard-  j 

j 

ware  to  the  extent  necessary  to  acliieve  the  optimum  ir  relia-  | 

bility  and  supportah  i 1 i ty  at  least  cost,  and;  (2)  n.axiiiiuir  | 

utilization  of  items  already  supported  by  the  supply  system  so 

1 

as  to  avoid  av  increase  in  the  range  ard  depth  of  items  to  be  1 

i 

supported.  Thus,  durirg  trade-off  studies.  Project  Managers 
should  require  systenss  engineering  to  identify  and  exploit 
opportunities  to  use  interchangcablr  items  for  similar  func- 
tions in  order  to  achieve  optiR>uiri  commonality  within  tlieir  par- 
ticular systems. 

l.  Snf ety . Safety  imst  also  t e considered  during  trade- 
off studies  to  assure  the  protection  of  indivifluols  from  injury 
or  death  and  to  prevent  damage  to  or  loss  of  equipment  or  pro- 
perty. Alternatives  under-  consideration  must  not  violate  safety 
regulations  such  as  those  pertaining  to  classification  of  ex- 
plosives for  haijdlirg  purposes,  detertion  and  warring  systeris, 
etc.  Alternatives  niust  also  not  violate  special  Project  Manage- 
ment needs  such  as  fail-safe,  redundancy , crashworthiness. 
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egress,  ard  rescue  niid  survival  f>r<>cedures . 


Pi.  Integrated  logist-ic  Suppott.  The  alternative  selected 
during  a trade  study  should  reflect  the  inclusion  of  reliability, 
niaintaiiiability , personnel,  hun<aii  factors,  safety,  siii)port 
eiiuipmenl  , spares,  training,  and  facilities  considerations. 

The  alternative  sliould  also  reflect  sucl;  tilings  as:  who  sup- 

ports what;  flow  from  producers  to  users;  shipboard  liat.dling 
tecliniques ; provisioning  recommendations  based  on  usage  rates 
or  failures  expected  per  time  period  and  the  tine  ships  can  be 
expected  to  he  out  of  r anj;e  of  suppor't  facilities;  inventory 
control  procedure  reconunendat  i ons  relative  to  sliji  schedules 
and  supply  center's;  r-ecomniendatioris  as  to  tlie  disposition  of 
failed  parts;  functional  module  substitution  concepts;  identi- 
fication of  long  lead  time  equiiwient;  recomniendat  i or  s applicable 
to  training;  recoruriondati  nns  applicable  to  tl.e  tactical  supply 
system  (e.g.,  underway  replenishment,  ship  spares,  AE  spares, 
transfer  of  re-pair-  uarts  ar.tl  weapons  or  equipment  from  dockside 
or  barge  to  ship);  recommendations  applicable  to  n.aintenance 
echelor.s  (e.g.,  shijiloard,  shop,  tender,  contractor,  field  en- 
gineer, sl:it>yard,  factory);  and  integrated  test  requ i r-emeiits 
based  on  criteria  such  as  fault  detection  and  correction  routines 
for  all  combat  systems  electronics  shall  he  run  daily,  or,  ex- 
pendable ordrat  ce  shall  not  he  tested  aboard  shiji,  etc. 

6.  Documenting  Trade-Cff  Studies.  Trade-off  studies  should 
be  described  in  documents  such  as  Proposed  Technical  Approaches, 
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I Concept  Kxploratior  T^eports,  Ship  Acouii&iiion  Plans,  Desii^n 

I Histories,  TFW  reports  or  trade-off  descriptions.  Such  re- 

I 

J ports  constitute  a continuing;  historical  record  of  all  trade- 

off decisions  made  aid  the  desi^n/capahility/cost  alternatives 
considered  durinp  the  sliip  systefi  life  cycle.  A sar.pl  c outline 

I 

of  a trtide-off  descripti oii/report  is  included  in  Appendix  A, 

! 

pa^e  A-16.  All  of  ttie  entries  shown  are  self-explanatory. 

7.  A Hypothetical  Example. 

Engineering  is  responsible  for  the  definition  and  technical 

t ■ 

integrity  of  interfaces.  Durintt,  the  ship  system  design  process, 
system  engineers  i<lentify  and  define  all  the  shipborne  systems 
needed  to  meet  functional  performance  requirements.  Interface 
documentation  is  developed  which  initially  delineates  broad 
performance  descriptions  or  reriuij  ererts  hut  which  is  eventu- 
ally expanded  into  detailed  interface  dbscripticns  reflecting 
a compatible  system.  The  documei»tatioi.  eventually  serves  as  a 
basis  for  Configuration  Change  Control  and  Accounting  and  is 
used  to  demonstrate  ttiat  compatiid  1 i ty  does  exist  and  tiiat  all 
appropriate  interface  characteristics  have  been  examined. 

Suffice  to  say  tliat  engineering  interfaces  provide  fertile 
ground  for  selecting  paiameters  for  technical  i>erformance 
I measurer»ent . 

During  ship  system  design,  performance  requirements  may 
be  allocated  to  the  various  functional  areas  or  Work  Breakdown 
Structure  (WBS)  elements  in  terms  of  interface  constraints. 
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that  if>,  support  ar>d  enviruitniental  relatior.Bliips,  space  icla- 
tionships,  or  functional  rclationsliips . For  example: 

••  Support  relationsiiips  refer  to  the  external  services 
that  must  be  supplied  to  shipborne  systems  in  orctci  that  these 
systems  can  satisfactoj i 1 v perform  their  intended  function 
(e.g.,  they  need  cooling  water,  electrical  power,  etc.). 
"Environmental”  relationships  refer  to  the  limitati ors/constrainte 
of  shipborne  systems  in  areas  such  as:  magnetic  fields,  temp- 

erature, humidity,  shock,  vibration,  ice,  wind,  precipitation, 
noise,  degree  of  enclosure,  and  salt  spray. 

• • Although  not  strictly  a matter  of  performance,  ary 
position  or  distance  reouirements  for  a shipborne  system/eauio- 
ment  relative  to  the  ship  or  other  systeri/equipcnent  as  may  be 
necessary  to  satisfy  the  intended  use  or  opeinticnal  require- 
ments must  be  specified.  For  exanple;  external  connections 
and  dimensions/configuration  (length,  width,  diameter,  height, 
and  associated  tolerances);  projections  and  door  swings;  tray 
or  module  pullout  space  or  removal  ureas;  areas  to  be  clear  of 
and  areas  provided  for  pipes,  ducts,  and  cabling;  areas  to  re- 
main clear  for  maintenance  access,  aiul  access  ports  or  doors; 
operational  areas  ai^d  arrangements  or,  orientation;  bolt-hole 
patterns,  mounting  hole  siees,  mounting  pad  sizes,  thread  sire, 
and  bracing  requirements,  if  any;  weight  and  location  of  the 
center  of  gravity,  finish  and/or  the  c) arncter isti cs  of  the 
material  to  which  the  system/equipment  is  to  be  in  contact. 
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••  In  the  electri col/el ectroric  tueu,  functioral  coneid- 
erations  pertain  to  intelligence  signalfi  flowing  between  the 
ship  and  potential  targets,  or,  through  sliipborne  ey6tcs‘/equii>- 
inent  interfaces.  In  the  mechanical  area,  functional  considera- 
tions pertain  to  tlie  dynamic  load  - transferring  capsMlities 
between  sliipborne  systers  or  between  sliipborne  systems  and  tlie 
ship,  Tlie  primary  interest  in  the  electrical/electronic  area 
is  functional  integration  of  the  combat  system.  Performance 
requirements  are  assigned  and  allocated  to  the  various  major 
components  of  the  combat  syster.:  in  such  a way  as  to  meet  opera- 
tional requirements  and  achieve  functional  integration.  It 
can  be  surmised,  for  example,  that  the  power  and  range  of  a 
tracking  radar  of  a surface  ship  definitely  limits  the  capa- 
bilities of  the  combat  systen..  It  is  very  important,  there- 
fore, to  assign  performance  requirements  to  tlie  tracking  radar 
which  will  allow  the  combat  systeni  to  meet  those  operational 
requirements  pertaining  to  range  (e.g.,  "the  surveillance  sys- 
tem must  be  capable  of  detecting  and  tracking  air  taigets  tra- 
veling at  mach  a,  up  to  400K  yards  in  range  and  lOOK  feet  in 
altitude").  In  the  mechanical  area,  some  shipborne  systems, 
such  as  missile  launchers  and  missile  handling  systems,  per- 
form non-static  functions  by  engaging  or  matins  with  other 
areas.  In  these  cases  interface  constraints  are  expressed  in 
terms  such  as:  configuration/dimensions  and  tolerances  for  all 

non-permanent  tiating  sut  faces;  weight  and  CG  location  of  loads 


iaipoHed  as  a result  of  enKaKement/natini;  and  amount  aid  direc- 
tion of  forces  required  to  move  and  to  engage  or  disengage; 
specific  areas  upon  whicli  no  load  may  be  imposed;  overall  en- 
velope and  direction  and  amount  of  motion  required  for  eitgage- 
ment  or  disengagericr^t ; and,  type,  eeigbt,  hardness,  linear  ex- 
pansion and  susceptibility  to  erosion  of  the  mating  or  engag- 
ing surfaces. 

For  tliis  hypothetical  example,  imagine  the  interface 
between  the  Poseidon  missile  and  the  Trident  submarine.  This 
is  a very  coiriplex  interface  between  two  systems  whicli  have 
not  been  built  before.  And,  to  ccinplicate  niatteis,  the  two 
systeiiis  are  under  tlic  cognisance  of  two  different  crgani/a- 
tions.  The  point  I wish  to  make  again  is  that  the  interface 
area  provides  fertile  ground  for  TPW.  For  this  example  then 
let's  consider  a siiiiple  paraii>etcr,  , within  the  intei  face 
and  assume  it  is  defined  as  a function  of  w,  that  is,  P^  = 


The  stops  in  the  TPM  process  were  descilhed  in  pages  ”, 

P,  and  9.  I have  already  coaipleteil  the  first  step  by  select- 
ing the  parameter,  P^,  for  measurement.  The  next  steps  are 
to  develop  subjective  probahilitj-  distributions  for  Wj , 
the  inputs,  by  making  inquiries  of  design  persor.nel  and  to 
simulate  values  for  Pj.  Thia  process  is  described  on  pages 
e and  9 and  in  reference  M)  so  will  not  be  repeated  here.  It 
is  importaiit  to  rcte,  however,  that  these  simulations  should 
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be  scheduled  to  coincide  with  important  events  during;  the  life 
of  the  project,  such  as  preliminary  desipr  review.  It  is  also 
Importtint  to  note  that  target  <n  hat-el  ine  values  of  Pj  must 
be  selected  as  a basis  for  w^,  *2*'**n  subjective 

probability  distributions.  For  example:  eacti  value  assigned 

to  a TPM  parameter  may  be  a specification  or  contractually 
specified  value;  a design  goal  determined  by  engineering  oi 
project  nianagement  to  represent  the  best  attainable  perfomai'ce 
• r the  value  predicted  for  neasurerient  at  a specified  verifi- 
cation event  ^ tliis  is  a "planned”  value  and  it  may  be  differ- 
ent at  each  event  or  it  nay  rernain  constant  with  time  --  a 
plot  of  planned  values  versus  time  is  known  as  the  "profile"  -- 
a sample  profile  is  shown  on  page  A-IS  of  Appendix  A.J  . A 
control  value  which  represents  the  most  likely  limit  or  toler- 
ance for  a planned  parameter'  at  a spccific«l  veification  event 
must  also  be  developed,  sec  page  A-15. 

The  last  ste(>s  are  trackii»g,  variarce  analysis  if  required 
and  reporting  if  required  to  bring  a problem  to  tlie  attention 
of  maaager;ert.  Here  again,  this  process  was  described  on 
pages  9 and  10  and  will  not  be  repeated  here.  Reporting  should 
be  tailored  to  the  needs  of  the  project.  Variance  analysis, 
or  compatibility  analysis  in  the  case  of  interfaces,  must  be 
performed  as  required  and,  if  necessary,  trade-offs  i>sust  be 
*ade  to  assure  compatibility. 


Conclusions 
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According  to  reference  (6):  Lord  Kelvin  is  quoted  as 

saying,  "When  you  can  measure  what  you  are  speakinr  about  and 
express  it  in  numbers,  you  know  something  about  it;  but  when 
you  cannot  express  it  in  numbers,  your  knowledge  is  of  a meager 
and  unsatisfactory  kind."  In  my  opinion  then  the  notion  of 
TPM  appears  to  be  very  attractive  as  a tool  to  measure  techni- 
cal progress,  and  to  identity  ana  control  risK.  And  it  ap- 
pears to  me  to  be  a worthwhile  endeavor  when  we  are  in  the  de- 
sign stages  as  well  as  when  we  have  developmental  liardware 
available  for  teat. 

The  benefit  of  implementing  a TPM  system  should  certainly 
exceed  the  cost  when  technical  risk  is  apparent.  And,  what  is 
the  cost?  I cannot  provide  any  rules  of  thumb  to  answer  this 
question.  It  would  depend  on  many  thinits  such  as  the  number 
of  parameters  being  tracked  and  reporting  requirements.  Cost 
must  be  negotiated  in  escn  case.  My  ma^or  point  here  is  that 
me  TFM  system  seems  to  oe  worth  the  efiort  in  developmental 
programs . 

ihere  are  no  textbooks  dealing  with  TPM  and  trade-offs. 

Tile  best  source  of  detailed  guidance  for  Tl'M  however,  appears 
to  be  reference  (3).  There  are  no  all  encompassing,  simple 
references  pertiueut  to  traae-oils.  It  is  noped  that  the  gen- 
eral guidance  provided  in  this  paper  will  satisfy  the  needs  of 
a number  of  project  managers. 

3R 
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ANNOTATU)  HlHI.lOr.KAPHY 


1.  MlL-STlJ-'lUU  (USAF),  Syt-'lcm  Enn'ii^eet  i nt;  Mai  ager^cnt 

Thie  Htandard  proviitee  syfiter;  enfi^ineerinK  managenient  re- 
quiremeiite  which  can  lie  tailored  to  project  needs.  It 
introduced  the  concept  of  TPM  and  includes  a desoiptioii 
of  requi  renienta  apfilicahle  to  TPM  and  trade-off  studies. 

2.  CODSIA,  Need  Use  Analysis,  Systens  Engineering 

This  study  empliasi >r.cd  the  need  for  a integrated  systens 
engineering  effort.  It  was  sponsored  by  DL'R&E  in  conjunc- 
tion with  the  Count  1 1 of  Def  e n s e/Indiistry  Associations. 

3.  SPACE  DIVISION,  NORTH  AMERICAN  ROCKWELL  CORPORATION, 

Technical  Perf oiinance  Mensurement  Guide 

This  guide  provides  criteria  and  recommended  techniques 
which  may  be  used  to  implement  established  TPM  requirements. 

4.  TIMSON,  F.S.,  Measuremciit  of  Technical  Performance  in 

Weapons  SystePi  Revelopment  Programs:  A Stibjective  Proba- 

bility Approach.  Preuared  for  ARPA  by  the  Rand  Corporation, 
December  19C8. 

Tills  paper  preseiits  an  exploratory  effort  to  develop  the 
frai:ework  of  a procedure  for  the  collection  ard  aralysis  of 
data  on  uncertainty  and  progress  regarding  teciinical  per- 
formance in  weapon  systeii:  development. 

5.  UCLA,  SCHOOL  OF  l-.NGINLERING  AND  APPLIID  SCIENCE,  Case  Studies 
in  Computer  Simulation,  TRANSIM,  Activity  Network  Analysis 

of  Ship  Acquisition  Project  Managenient.  Prepared  for  the 
Office  of  Naval  Research  by  UCLA,  Septei.ber  1970. 

This  report  describes  a Monte-Carlo-type  computer  simulator 
esjiecial  12"^  applicable  to  solving  problems  associated  with 
ship  acquisition. 

6.  TRW  SYSTEMS  GROUP,  Technical  Performance  Measurement,  Presented 
by  Giyora  Doeh  at  the  ASPR  Institute  Seminar  on  System 
Engineering  Management,  Los  Angeles,  California,  December 

4,  1969. 

This  pi esentation  coveis  a TPM  system  established  by  TRW, 
Redondo  Reach,  California. 
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, U.S.  ARMY  SAFEOl'AR!)  SYSTEM  COMMAND,  Tect.nical  Specifica- 
tion 705-43S,  Site  Uefenee  of  Miimteran,  Technical  Perfor- 
mance Measurenient , March  1972. 

This  specification  describes  the  TPM  systeci  used  by  Martin 
Marietta  and  McDonnell/Douglas  in  the  SPRINT  Missile  pro- 
gram, a part  of  Safeguard. 

8.  SPACE  DIVISION,  GENERAL  ELECTRIC  CO.,  Technical  Performance 
Measurement  (TPM),  Guidelines  for  a Compliant  System. 
Presented  by  Mr.  A.E.  Miller  at  the  ASPR  Institute  Seminar 
on  System  Engineering  Management,  Los  Angeles,  California, 
December  4,  1969. 

This  presentation  covers  a TPM  system,  compliant  with  MIL- 
STD-449,  developed  by  the  Valley  Forge  Space  Division, 
General  Electric  Co. 

9.  NAVSHIPS  NOTICE  4121  dated  6 March  1972,  Specifications 
Control  Board  and  Cost-Benefit  Analysis  Procedures. 

This  notice  provides  the  basic  cost-benefit  analysis  pro- 
cedures used  by  the  Naval  Ship  Systems  Command. 

10.  D.R.J.  White,  D.L.  Scott,  and  R.N.  Schulz,  POED  - A Method 
of  Evaluating  System  Performance,  IEEE  Transactions  on 
Engineering  Management,  December  1963. 

This  article  described  POED  (Performance  Organization  for 
Evaluation  and  Decision)  which  is  an  evaluation  and  deci- 
sion technique  which  permits  computing  performance  of  a 
device,  equipment,  system  or  system  complex;  compares  and 
scores  this  performance  against  requirements  or  value  judge- 
ments representing  user's  needs;  and  organizes  results  in 
a useful  manner  so  that  assessment  of  value  is  readily 
achieved. 

11.  CDR.  B.L.  Potts,  Equipment  Readiness,  Working  paper  No.  3T> 
ASW  Force  Level  .Study. 

This  paper  describes  a computer  model  which  was  constructed 
for  use  by  the  ASW  Force  Level  Study. 
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APPENDIX  A 


SAMPLE  TPM  TRACKING  AND  OUTPUT  REPORTS 


TABLE  I 


PROBABILITY  DISTRIBUTIONS  FOR  SPEED  OF  HYPOTHETICAL  SHIP  AT 
THRLE-MONT!'  INTERVALS  DURING  DSI’E-LOPIffiLT 


0 mo 

3 mo 

IIQ^yil 

9 mo 

12  mo 

15  mo 

mgt 

21  mo 

l6  knots 

.15 

.20 

.15 

.10 

.05 

.05 

.00 

17  knots  1 

.20 

.30 

.30 

.30 

.25 

.20 

.20 

l8  knots 

.25 

.30 

.35 

.35 

.ho 

.50 

.55 

19  knots 

.10 

.25 

.25 

.25 

.25 

.25 

.20 

.20 

20  knots  j 

.10 

.00 

.00 

.00 

j 

.05 

.05 

i 

.05 

.05 

I 

i 


T/S-BLE  II 

INFORMATION  FOR  5T/ALUATION  OF  PROGRESS  AND  STATUS  OF  HYPOTHETICAL 

SHIP  develofme:;t  project  skolti  in  above  table 


Itcnr~^~ 

0 mo  j 

I 

3 mo 

6 mo 

j-5  mo 

21  mo 

p(V)  >17(l:not3; 

.75 

.80 

i .85 

.90 

.95 

.95 

1 .95 

1.00 

p(V ) > 19(Fnons  j 

.00 

.CO 

.00 

.00 

.05 

.05 

.05 

.05 

m('V)  (knots) 

17.5 

17.6 

17.7 

17.8 

17.9 

18.0 

is.o 

18.3 

£t(V)  (knots) 

.7 

.6 

.5 

.4 

.h 

.3 

.2 

. 7 

Dollars  Con- 
sumed (Mil- 
lions ) 

Time  Interval 

negli- 

gible 

6 

10 

12 

13 

13 

15 

15 

(mo) 

Dollars  ,}...uain- 

0 

3 

3 

3 

3 

3 

3 

3 

ing  (Millions) 
Time  Remaining 

100 

qU 

8U 

72 

59 

U6 

31 

16 

(mo) 

2lt 

21 

CO 

15 

12 

9 

6 

. J 

3 

where,  /t<(V)  is  the  meun  value  of  speed  and  ct(V)  is  the  standard  deviation 
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I 
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iti 


tti-rliirinifii 


MAGNITUDE  OF  THE  STANDARD  DEVIATION  PROBABILITY 


PROB;'.BILnY  OF  MEETING  OR  EXCEEDING  MINIMUM  REQUIREMEOTS  AND  PROBABILITY 
OF  BEING  WITHIN  MAXIMUM  AND  MINIMUM  REQUIREMENTS  LIMITS 


TIME  (mo ) 


FIGURE  1 


MAGNITUDE  OF  STANDARD  DEVIATION  AT  THREE-MONTH  INTERVALE 


UNCERTAINTY 

REMOVED 

(PROGRESS) 


TIME 

REMOVED 


^®certainty 

RSMIWING 


TIME  (mo) 


TIME  REMAINING 


FIGURE  2 


CME  PARAMETER  PROGRESS  SUMMARY  December  1968 
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TPM  ACTION  ITEM.  PEPORT 


ACTION  ITEM 
REPORT  NR._ 

WBS 

CODE 


ISSUE 

NR. 


ORGANIZATION 

DATE 


DESCRIPTION 


PARAMETER 
NR. 

SPECIFICATION 
REQUIRE! 'ENT 
VALUE  (LIMIT) 


DESCRIPTION 


UNITS 


VERIFICATION 

POINT 


TEST/PLANNED 

VALUE 


DEMONSTRATED 

VALUE 


IWFACT 


PERFORMANCE 


SCHEDULE 


DISCUSSION 


ISSUE 

DATE 


APPROVALS 


A-5 


Figure  (■'>) 
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I I . T I T L I 


Technical  Performance  Mcasurctacnt  Report 


(U)S-ICZ'/ 


>.  ofsCRL'TIOKr/'.^UMPOlt  APPHOV^l^rn: 

I To  provide  visibility  to  the  propran/proi ect  manager  on  thci  11  August  1569 

I state  of  engineering  accomplishment  toward  the  contract  r"or>  icc~^f  p..imahy 

I requirements  as  compared  with  planned  and  required  values.  "csponsidh.(i  y 
I Provides  a basis  for  projecting  needed  supporting  efforts.  AFSC 


•.  DOC  RCQUIRro 


t.  APPROVAL  LIMITATION 


7,  APPLIC  AT  lON/INTCRREL  ATIONSMIP  I PCndiHJiJ  pUb  1 1 C 3 1 1 OP,  Ih 

These  data  are  related  to  the  design  requirements  (Part  I the  ADL,  ^ 
of  the  specification)  for  the  Configuration  Item  (Cl)  and  | 

to  its  critical  elements  and  design  parameters.  The  ..  rcf crences  f.-.r.nrfAroTpv.  . 

reportable  Cl  elements  and  parameters  to  be  included  in  tiock  toj  j 

this  report  will  be  those  listed  in  the  System  Pngincering  MIL-STD-499 
Management  Plan  incorporated  as  a contract  requirement  and  . ’ , 

will  be  identified  on  the  Dl)  Form  1423  either  by  attachment  ’ ' ‘ 

or  reference  to  the  SF.MP.  This  DID  will  normally  be  used 
only  when  MIL-STD-499  is  a contractual  requirement;  other- 
wise, DD  Form  1664  S-102  should  be  used.  Should  this  DID  ! 

be  preferred  to  S-102,  when  MIL-STD-499  is  not  a contrac- 
tual requirement,  the  task  effort  for  generating  this  data 

must  be  included  in  the  contract  work  statement.  — — — 1 


.4CSL  HUMUemS) 


10.  P « A ft  A r ir>N  I »I5  T n U c T ?o  V5 


1.  Tne  contractor  shall  prepare  a TPM  report (s)  on  designated  parameters.  The  | 

DD  Form  1423  will  specify  whether  a particular  report  will  cover  all  parameters 

of  a system  element.,  anS  individual  parameter,  or  selected  groupings  of  parameters. 

2.  For  each  parameter  selected  for  TPM  reporting, reports  shall  include: 

■ a.  The  demonstrated  value,  planned  value,  and  demonstrated  variance  for  the  ? 
design  at  the  time  of  the  TPM,  plus  tho  current  estimate,  the  current  specification 

t 

requirement  and  tho  predicted  variance  for  tho  end  product.  Determination  of  the  | 

« 

current  estimate  shall  be  based  on  the  demonstrated  value  and  the  changes  to  the 

i 

parameter  value  which  can  be  attained  within  tho  remaining  schedule  and  cost  baseline] 
The  format  shall  be  as  described  in  paragraph  3 below. 

I 

b.  Status  of  the  configuration  design  and  discussion  of  design  and  engineering  i 

I 

investigations  (e.g.  experiments  and  tests  performed)  and  analyses  which  support  j 
the  demonstrated  value,  and  discussion  of  the  technical  effort  which  supports  the  • 


JD.^r..i664 


Ar>e«AArA«^A«KMO«e* 


(r‘S-fevS>  (Continued) 

« 

Preparation  Instructions  (Continued) 
p idicted  profile  leadinR  to  the  current  ostiniato. 

c.  Variance  Analysis  to  include  discussion  of  design,  developnont,  and/or 
fcorication  problems  encountered  wJjich  cause  demonstrated  or  predicted  performance 

0 cside  the  planned  tolerance  band.  hTien  this  occurs  a revised  planned  value 
profile  will  be  ciaafcio5*e>d  as  shown  in  Figure  2.  The  contractor  will  report 

1 pacts  on  higher  level  parameters,  on  interface  requirements  and  on  system  cost 
effectiveness  if  appropriate.  For  performance  deficiencies,  alternate  and  proposed 
recovery  plans  and  associated  configuration  changes  will  be  reported  with  the 

j rformance,  cost,  and  schedule  implications  of  each. • For  performance  in  excess 
of  requirements,  possibilities  for  reallocation  of  parameter  requirements  and 
I _dgcts  will  bo  reported.  '' 

d.  Drawings,  layouts,  graphs,  etc.  as  appropriate  to  support  the  above. 

e.  When  discussion  called  for  by  this  data  item  is  covered  by  another  report 
•quired  by  the  DD  1423,  reference  thereto  in  lieu  of  repetition  shall  be  made. 

The  performance,  comparison  will  be  in  tabular  and  graphical  form,  with  the 
v.*bulation  as  shown  in  Figure  1 and  the  graph  as  in  Figure  2.  The  system  elements 
id  reportable  parameters/parameter  planncd-value-profilcs  as  exemplified  in 

Figures  1 and  2 will  be  defined  either  in  the  SEflP,  the  task  description  on 

o r Cl  . 

le  Cl-subsytem,  an  attachment  to  the  CDRL. 

...  • 

Definitions: 

, • 

a.  System  Element.  A discrete  "portion  of  a system.  A product  element  of 
ae  Work  Breakdown  Strvicturo  (WliS)  at  any  level  is  a system  element. 


(Continued) 

« 

Preparation  Instructions  (Continued) 

b.  Planned  Value.  The  anticipated  value  of  a parameter  at  a Riven  point  in 
he  development  cycle.  A plot  of  these  versus  time  is  known  as  the  Planned  Value 

Profile.  In  addition  to  the  planned  value  profile,  it  may  bo  desirable  to  indicate 
. range  of  acceptable  values  versus  time.  When  this  range  is  shown,  it  is  known 
IS  a tolerance  band. 

i 

I 

c.  Demonstrated  Value.  The  demonstrated  value  of  a technical  parameter  is 

;ho  value  which  is  estimated  or  measured  in  a particular  test  and/or  analysis.  ' 

d.  Specification  Requirement.  The  value  or  range  of  values  contained  in  a ! 

i 

contractual  performance  specification  or  allocated  from  such  a specification, 

1 

/ith  a verification  requirement  for  the  end  product. 

c.  Current  Estimate.  The  value  of  a parameter  predicted  for  the  end  product 
>f  the  contract. 

f.  Demonstrated  Technical  Variance.  The  difference  between  the  Planned 
Value  and  th;  demonstrated  value  of  a parameter. 

g«  Predicted  Technical  Variance.  The  difference  betv^ecn  the  Specification 
Requirement  and  the  Current  Estimate  of  the  Parameter. 
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reliability  for  the  Signal  Data  Converter  (SDC)  based  on  prediction  and 
limited  field  data.  Continued  assessments  will  be  made  as  Tartar  field  data 
is  received  and  analyzed.  Potential  major  design  changes  planned  for  the  MK  8l 
development  have  been  deferred  pending  RCA/NAVY  action. 
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